MarcDuerst Posted April 5, 2011 Report Share Posted April 5, 2011 Hi, We are currently evaluating a new SCM - a DVCS to be more exactly. Beside Git, Mercurial and others we also take a closer look on Plastic SCM. We created a sample workflow with several tests in to test all the DVCS products against the same use-cases / workflows. While doing this test for Plastic some general questions occur. Maybe someone can give us some tips here: Scenario is DVCS with two workstations (featuring local repos) and a central repo push/pull (Branches > Replication). 1) Both workstations change the same file. WS1 pushes. WS2 pulls and likes to get the changes from WS1 before commiting its own changes. In Git we uses Stash > Pull > Rebase > Stash Pop to get this. In Plastic WS2 seems to stay on an its older revision and as soon as we try to check it in a merge will be required. Can this be done somehow before attempting to check-in? 2) Ignore-files: Can we add an ignore file that totally ignore all directories called "ignore*"? 3) We have a common framework we use in many customer projects. Can we have it in a separate repository (or something like this) and reference/include it in the project repositories? Something like Subversions "externals" definition. If there is a way: can we specify the branch / version to reference? Any help on these topics would be great! Cheers, Marc Link to comment Share on other sites More sharing options...
MarcDuerst Posted April 5, 2011 Author Report Share Posted April 5, 2011 More questions came up during evaluation: 4) When merging branchs (happens often in DVCS configuration) one get fetch-branches created all the time. After merging them I am not able to delete them because an error telling me that it has revisions in use. Same applys to child-branches (I used them as features-branches => correct?). Can't be deleted because revisions in use. How can I get rid of temporary branches I don't need anymore? :-s 5) It can happen (eg. after resolving branch merge conflicts) after pushing changes to the remote server (again talking about DVCS setup) that fetch-branches are created on the target/destination machine. Somebody then needs to merge them on the target machine (eg. the server)?!?! I think I got something wrong here. It must not be that somebody needs to touch the server aka central master repository manually. I mean I resolved the branch merge already locally and then only like to push it to the remote repository. Right? #-o Would be great if someone can give me some input as we have a meeting today where a SCM desicion could be the topic :-$ Link to comment Share on other sites More sharing options...
MarcDuerst Posted April 5, 2011 Author Report Share Posted April 5, 2011 6) Is there a way to change the GUI so the detail views/panels are not stacked and need to be closed manually? Eg. something like regular tab-control behavior? Link to comment Share on other sites More sharing options...
John Posner Posted April 6, 2011 Report Share Posted April 6, 2011 Hi Marc, Hi' date='We are currently evaluating a new SCM - a DVCS to be more exactly. Beside Git, Mercurial and others we also take a closer look on Plastic SCM. We created a sample workflow with several tests in to test all the DVCS products against the same use-cases / workflows. While doing this test for Plastic some general questions occur. Maybe someone can give us some tips here: Scenario is DVCS with two workstations (featuring local repos) and a central repo push/pull (Branches > Replication). 1) Both workstations change the same file. WS1 pushes. WS2 pulls and likes to get the changes from WS1 before commiting its own changes. In Git we uses Stash > Pull > Rebase > Stash Pop to get this. In Plastic WS2 seems to stay on an its older revision and as soon as we try to check it in a merge will be required. Can this be done somehow before attempting to check-in? [/quote'] I'm not absolutely sure of your scenario, but ... in Plastic SCM, a workspace never gets updated automatically -- you must use the "Update" command. In your case, performing a "pull" from the central repo to the WS2 machine will create new revisions in the REPO of the WS2 machine. And then, performing an "Update" of the WS2 workspace itself will copy those new revisions from the local repo into the WS2 workspace. 2) Ignore-files: Can we add an ignore file that totally ignore all directories called "ignore*"? Yes. Find a directory that currently contains one of those "ignore" subdirectories. (If necessary' date=' create an "ignore" subdirectory.) Right-click the "ignore" subdirectory, and invoke the command "Add to ignored list". On the cascading submenu, select the first choice, in order to indicate that you want to process all directories named "ignore", not just the particular one that you just clicked. Now, a pop-up dialog appears. I'm guessing that you want ALL "ignore" subdirectories to be ignored, in ALL repositories, for ALL users. Unfortunately, there's no drop-dead-simple way to make that happen. You can go in either of these directions: * APPLY TO ALL "ignore" DIRECTORIES IN THIS REPOSITORY, FOR ALL USERS -- Leave the "Apply rule to all workspaces" checkbox cleared, and click Ok. This creates a private file, "ignored.conf", in your workspace's root directory. Place this file under source control. When other users update their workspaces that use this repository, they'll get this file. So future updates will bypass all "ignore" subdirectories. To get to the ultimate goal, repeat for all repositories. * APPLY TO ALL "ignore" DIRECTORIES IN YOUR OWN WORKSPACES -- Check the "Apply rule to all workspaces" checkbox, and click Ok. This creates/modifies the "ignored.conf" file under your home directory. It affects all future updates in all your workspaces. To get to the ultimate goal, repeat for all users. 3) We have a common framework we use in many customer projects. Can we have it in a separate repository (or something like this) and reference/include it in the project repositories? Something like Subversions "externals" definition. If there is a way: can we specify the branch / version to reference? Yes to both questions. See: http://www.plasticscm.com/infocenter/technical-articles/component-based-development.aspx 4) When merging branchs (happens often in DVCS configuration) one get fetch-branches created all the time. After merging them I am not able to delete them because an error telling me that it has revisions in use. Same applys to child-branches (I used them as features-branches => correct?). Can't be deleted because revisions in use. How can I get rid of temporary branches I don't need anymore? Eh? That one stumps me. I'll get you more help on this ... 5) It can happen (eg. after resolving branch merge conflicts) after pushing changes to the remote server (again talking about DVCS setup) that fetch-branches are created on the target/destination machine. Somebody then needs to merge them on the target machine (eg. the server)?!?! I think I got something wrong here. It must not be that somebody needs to touch the server aka central master repository manually. I mean I resolved the branch merge already locally and then only like to push it to the remote repository. Right? d'oh! If I understand your scenario correctly' date=' all merging should occur on the WS1 and WS2 machines, after which new revisions are created on the target branch ("/main" ??) in the local repository. In this case, a "push" to the central repo should never create a fetch-branch, but should always simply create one or more new revisions on the target branch. I think we need to look into this more closely -- step-by-step. 6) Is there a way to change the GUI so the detail views/panels are not stacked and need to be closed manually? Eg. something like regular tab-control behavior? Not at this point, sorry. Link to comment Share on other sites More sharing options...
psantosl Posted April 6, 2011 Report Share Posted April 6, 2011 > We are currently evaluating a new SCM - a DVCS to be more exactly. > Beside Git, Mercurial and others we also take a closer look on > Plastic SCM. We created a sample workflow with several tests in > to test all the DVCS products against the same use-cases / workflows. Ok, sounds like you've a nice challenge!! > While doing this test for Plastic some general questions occur. > Maybe someone can give us some tips here: I'll try to add to what John already answered! > Scenario is DVCS with two workstations (featuring local repos) and > a central repo push/pull (Branches > Replication). > 1) Both workstations change the same file. WS1 pushes. WS2 pulls > and likes to get the changes from WS1 before commiting its own > changes. In Git we uses Stash > Pull > Rebase > Stash Pop to get > this. In Plastic WS2 seems to stay on an its older revision and > as soon as we try to check it in a merge will be required. > Can this be done somehow before attempting to check-in? You mean merging before? You can "merge from this branch" selecting the branch you're working on... then you do exactly the same you'd do on "checkin" (merge first) but running the merge manually (I mean, launching it yourself). Note: we're changing part of this behavior in Plastic 4.0. With the scenario you describe you won't end up with a "fetch branch", but if you checkin before pulling, you will. In 4.0 we totally removed fetch branches to make it simpler. > 2) Ignore-files: Can we add an ignore file > that totally ignore all directories called > "ignore*"? I think this one has been pretty well covered by John. > 3) We have a common framework we use in many > customer projects. Can we have it in a separate > repository (or something like this) and > reference/include it in the project repositories? > Something like Subversions "externals" definition. > If there is a way: can we specify the branch / version > to reference? Again, John pointed in the right direction. > 4) When merging branches (happens often > in DVCS configuration) one get fetch-branches > created all the time. After merging them I > am not able to delete them because an error > telling me that it has revisions in use. > Same applys to child-branches (I used them > as features-branches => correct?). > Can't be deleted because revisions in use. > How can I get rid of temporary branches I > don't need anymore? Eh? You hitted a good point here. Our phylosophy is: "don't delete anything". I know git users are very used to "rewrite history" but that's something we preferred to keep as immutable as possible. Whether we're right or wrong is probably a matter of taste... I'd like to add "delete branch" functionality soon (it takes like a few hours to implement, I even have it on a branch sitting since long ago) but, as I said, is more a matter of desired behavior... We like to preserve feature branches to keep traceability... Don't you find it useful? > 5) It can happen (eg. after resolving > branch merge conflicts) after pushing > changes to the remote server (again > talking about DVCS setup) that fetch-branches > are created on the target/destination machine. > Somebody then needs to merge them on the > target machine (eg. the server)?!?! > I think I got something wrong here. > It must not be that somebody needs to touch > the server aka central master repository manually. > I mean I resolved the branch merge already > locally and then only like to push it to the > remote repository. Right? d'oh! You're right... This is a little "shortcoming" of the current "fetch branch" approach we're using in 3.0 and previous versions. The only thing I can say here is... it works as you'd expect in the upcoming (soon) 4.0... > 6) Is there a way to change the GUI so the > detail views/panels are not stacked and need > to be closed manually? Eg. something like > regular tab-control behavior? You're *really* asking for 4.0, aren't you? Check this: Link to comment Share on other sites More sharing options...
MarcDuerst Posted April 7, 2011 Author Report Share Posted April 7, 2011 Hi, First of all let my say thank you to both of you. Nice and detailed answers that explains a lot. It looks like most of our open questions are answered and finally looking good. But... the real killer is the one where fetch branches gets created on the server. This really never should happen as these changes will be lost then as nobody will work on the server directly. If anything is wrong (conflict) when pushing changes the push must be rejected/fail and resolved on the client/local repo and then tried to push again. As you guys wrote this will be "fixed" in V4. Do you have any time-frame for V4? Is it more summer 2011 or 2012? :-" The second important but maybe not killer issue is the one where I like to get changes on a file somebody else and I changed. I am not sure yet how this scenarion is handled/addressed by Plastic. So here is what I like do: 1) Change FileA.cs on workstation 1 (don't commit yet). 2) Change FileA.cs on workstation 2. 3) Commit and push change from workstation 2. 4) How can workstation 1 now get the changes from workstation 2 and continue work on FileA.cs before commit the final version? I tried: 4) Workstation 1 pull's. 5) FileA.cs still shows the same as in 1) and is missing changes from 2). 6) Commit it on workstation 1 fails because now I have to merge it with the changes I got from workstation 2. 7) Merge and commit again. 8) Push The point is that I like to get "updates" for files I am currently working on without loosing my work in progress (in case somebody else did some fixes I need too to the same)). All before commit my changes. Any input to this one would be great, thanks! Marc Link to comment Share on other sites More sharing options...
psantosl Posted April 7, 2011 Report Share Posted April 7, 2011 > First of all let my say thank you to both of you. > Nice and detailed answers that explains a lot. > It looks like most of our open questions are answered > and finally looking good. Remember Plastic is not only about the product... is about the best support team!! > But... the real killer is the one where fetch > branches gets created on the server. This really > never should happen as these changes will be lost > then as nobody will work on the server directly. > If anything is wrong (conflict) when pushing > changes the push must be rejected/fail and resolved > on the client/local repo and then tried to push again. > As you guys wrote this will be "fixed" in V4. Do > you have any time-frame for V4? Is it more summer 2011 or 2012? My expectation is to release it before summer 2011, in fact, we're working like crazy to make it happen ASAP. When do you need to jump to the new system?? I wonder if we can send you a pre-release. > The second important but maybe not killer issue > is the one where I like to get changes on a file > somebody else and I changed. I am not sure yet > how this scenarion is handled/addressed by Plastic. > So here is what I like do: Let's go: > 1) Change FileA.cs on workstation 1 > (don't commit yet). > 2) Change FileA.cs on workstation 2. > 3) Commit and push change from > workstation 2. > 4) How can workstation 1 now get the > changes from workstation 2 and continue > work on FileA.cs before commit the final > version? Didn't I cover it in my previous answer? It is easy: suppose you're working on /main/task001. Ok, after the upsh from Wk2 simply do "merge from /main/task001" > I tried: > 4) Workstation 1 pull's. > 5) FileA.cs still shows the > same as in 1) and is missing > changes from 2). Yes, you need to run an "update" to get the latest changes (in case you modified FileA.cs and FileB.cs on wk2, you'll get FileB.cs, the FileA.cs won't be downloaded since you need a merge) Do a merge from the branch, merge against your checked out FileA.cs and you're done. > 6) Commit it on workstation 1 fails because > now I have to merge it with the changes > I got from workstation 2. > 7) Merge and commit again. > 8) Push > The point is that I like to get "updates" for files > I am currently working on without loosing my work > in progress (in case somebody else did some fixes > I need too to the same)). All before commit my changes. Just launch the merge after the pull from the other workstation and you're done. pablo Link to comment Share on other sites More sharing options...
MarcDuerst Posted April 7, 2011 Author Report Share Posted April 7, 2011 Support is great - agree ;-) Thanks for sharing your schedule. Folks here like to go to the new DVCS asap. as your main server still runs on an old Perforce. To be fair I have to say that it looks like GIT will make the race followed by Plastic as more geeks here vote for GIT (they already know it, Open-source, etc). But final decision is not yet made. ...maybe in an hour or two I really like Plastic because of its simplicity (comparing to GIT *smile*) and probably will use it in the future anyway (for personal stuff). Thanks for taking a second try explaining me the second use-case. Think my problem was that I did not use a feature-branch at that time. This would explain it, I guess. Cheers, Marc Link to comment Share on other sites More sharing options...
psantosl Posted April 7, 2011 Report Share Posted April 7, 2011 Ok, we'd love if you go for Plastic, but I understand you'll be better served by 4.0. Once thing Miller is going to highlight is that the "fetch branch" issue can be totally avoided if you go for "feature branches". Simply, totally avoided. Don't forget to remember your "geek friends" that when a team uses a product it can save enormous amounts of time if they count with a "legendary support" like ours . Not as easy to get the same level from the git community... Link to comment Share on other sites More sharing options...
dave.wallace Posted June 29, 2011 Report Share Posted June 29, 2011 Interesting reading guys, thanks, can I hijack this thread? Good! A few points raised and answered left me with a few further questions: 1. How can feature-branches be used to avoid that extra branch on the server problem? I mostly understand the problem discussed, but moreso I understand that our staff will most likely use the same workflow Marc described. Could someone please go into a more depth about this? 2. This may not even be a problem, but what if changes and branches do get overlooked/lost on a remote server, is this the sort of situation that has no remedy? or is it possible to work directly from the server to er.. "tidy up" if that needs to happen occasionally? I may be approaching this fro the wrong angle entirely. 3. Pablo - the deletion of branches (or lack thereof) is an ethos I agree with, I think though that during a trial period where configurations and setups aren't necessarily what you actually want to roll with on formal deployment of DVCS. In my case I made a few errors and made a mess because I'm new to version control (for shame! hey.. at least we're doing it now). cheers! Dave Link to comment Share on other sites More sharing options...
psantosl Posted June 30, 2011 Report Share Posted June 30, 2011 Hi Dave! > A few points raised and answered > left me with a few further questions: > 1. How can feature-branches be > used to avoid that extra branch > on the server problem? I mostly > understand the problem discussed, > but moreso I understand that our > staff will most likely use the > same workflow Marc described. > Could someone please go into a > more depth about this? If I understand correctly you're talking about "fetch branches", aren't you? If so, the point of using feature branches is to specifically avoid working on the same branch on different sites (repositories), hence avoiding collisions (conflicts) on the same branch. That's all. > 2. This may not even be a problem, > but what if changes and branches > do get overlooked/lost on a remote > server, is this the sort of situation > that has no remedy? or is it possible > to work directly from the server to er.. > "tidy up" if that needs to happen > occasionally? I may be approaching this > fro the wrong angle entirely. Well, if you've two servers at two sites, each of them will be the "local" server for a different team. I doubt the "local team" will "forget" about the branches they own. Anyway, you can always have scripting to run replicas... so no way to forget. In 4.0 we've just added the "synch view": http://codicesoftware.blogspot.com/2011/06/distributed-synchronization-view.html > 3. Pablo - the deletion of branches > (or lack thereof) is an ethos I > agree with, I think though that > during a trial period where > configurations and setups aren't > necessarily what you actually want > to roll with on formal deployment > of DVCS. In my case I made a few > errors and made a mess because I'm > new to version control (for shame! > hey.. at least we're doing it now). We added "delete changeset" to 4.0, which will let you end up with an empty branch... which in turn you can delete... Cheers! pablo Link to comment Share on other sites More sharing options...
dave.wallace Posted June 30, 2011 Report Share Posted June 30, 2011 Awesome, thanks for the prompt reply as always Pablo. It looks like I've convinced our team to give PlasticSCM a crack which is great, I feel its intuitive enough for even some of our non-techies to get their hands dirty. Also, 4.0 sounds mega - can't wait! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.