Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


CG last won the day on December 13 2012

CG had the most liked content!

Community Reputation

2 Neutral

About CG

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2,020 profile views
  1. CG

    sync bug

    And just because it should be said...in my opinion this is hands down the best version control system available today. Keep up all the good work and innovative ideas!
  2. CG

    sync bug

    That's great! Good to know! Thanks!!
  3. CG

    sync bug

    One more point/question...since you recommend not using changesets and say they aren't very relevant...is there an alternative method for creating xlinks that uses the GUID instead of a changeset? Cloning a repo to a new server where "relative xlinks" are used means that the changeset link will break, right? Since the changesets will be different after a clone?
  4. CG

    sync bug

    I still use SQL Server as the back end. It fits within our existing backup scheme without issue (each repo database is automatically included in the backup and maintenance scheme--tran logs every 15 minutes, diffs each night, weekly fulls, snapshots to SAN, then weekly/monthly/quarterly/yearly tape archives, etc). So it's just easy to stick with SQL. I like your method of using the GUI and placing it in the product name. I'll switch over to that. In the past the changeset wasn't a big deal because the builds were all run against the central "gold" repository of truth. So clients syncing with it is a non-issue since the official builds come from it, and a changeset won't ever change it's number once it is made. So by embedding it int he product version info (instead of the product name) we can always tie it back. My issue with this post was that by trying to move the repo to a new location (not snycing it with an existing repo with contents, but really moving it) I lost the changeset link to the builds. It's not that big a deal because we still have labels for every build that was released so we can tie back, it's just not as clean. So yes, good tip about the GUID, and that makes sense (it's just a little unwieldy to put the GUID in the build instance names in our devops tool as seeing a repo and changeset number was simpler). But it makes more sense as it truly is unique across all working instances of the repo (it's just harder to search on and say to someone over the phone).
  5. CG

    sync bug

    As a followup, this makes it impossible for me to move a repository to a subrepository and maintain an accurate copy. We include the changeset from which a build was made in the version info of an .exe or .dll. If we want to move a repo then that breaks that metadata link since there's no way to copy/clone the repo to a subrepo and preserve changesets. Unless you have another suggestion on how I can get a 1:1 copy of a repo into another new empty repo (or sub repo). Thanks.
  6. CG

    sync bug

    Just one sync view, pushing all branches from a single repo to an empty repo. I had expected the changeset ordering the remain the same since the target repo was empty. I understand changesets might change with merging repos that had to be reconciled with changes in each, but having no changes in one I thought I could get an exact copy. So....I wiped it out and tried clone instead. I expected clone to make an exact copy...but even that fails. Clone is not preserving changesets. As far as I can tell they are chronologically correct (i.e. every changeset is greater than the changeset that can before it). However if my source repo has gaps in changesets (due to a delete for example) then those gaps don't propagate via clone. Example, my source repo I'm cloning has changesets 1,2,5,7,8 then after cloning my destination repo has changesets 1,2,3,4,5. I understand why changesets with replication can be off (but I don't like that they chronologically off), but I would expect clone to actually clone and that I'd have an exact copy of what I'm cloning. Changesets shouldn't change with a clone.
  7. CG

    sync bug

    You have a bug with your sync views where they don't synchronize as expected (at least I would consider this a bug). I just synced an existing repo into a blank sub repository. The behavior was not as expected. Changeset numbers DO NOT match up! In fact, the head (latest changeset) in my source repo does not even exist in my destination repo. All of the changesets themselves seem to be present, but the numbers are all over the place. For example, my last changeset on my last task branch in the old repo was 807. I merged that into my main branch and the very last changeset there is 808. In the new repository (that was previously empty before the sync) my last task branch changeset is 727 and the last changeset on main is 349! How can changesets go down in number for later commits? As another example see the attached screen shot showing a short section where changests are not sequential in time (later numbers show as earlier commits). It's my understanding that changesets should always increase with chronological commits. Is that not the case? In normal operation (outside of a sync) changeset work this way. Also, sync view is listed as being a way to keep repos in sync with one another. If my "mirror" repo has different numbered changesets then it's not a mirror!! Attached are snippets from then branch explorers of the "correct" (i.e. the original repo) and the incorrect (the new repo) changesets (I manually labeled the changeset in black since I didn't see a way to get the branch explorer to display the CS numbers).
  8. Nice. I never had an occasion to create a subrepo, that makes sense. Thanks! Regarding Jet...it sounds great for speed but I like the transparency and accessibility of SQL Server (being able to use TSQL). I've had minor issues in the past (regarding dangling workspaces when clients were removed without removing their workspaces) where directly modifying the data for a workspace in the SQL table fixed the problem (this was a few years ago). Not having the ability to query/modify Jet data could be an issue. At least with SQL I know that I have an extra layer of visibility into the underling storage system so that if anything goes wrong (corruption for example) and I don't have a recent enough backup for some reason (or a backup wouldn't help, like in my above problem) then I still can potentially fix the issue. The completely closed nature of Jet keeps me relying on my trusted SQL server. Do you have Jet tools (even command line would be fine) that allow for query/update capability if needed? Or do you publish the Jet structure/standard anywhere?
  9. At some point years ago in an early version of Plastic I seem to vaguely remember discussion of an undocumented ability to configure Plastic to use a single database on a server and use multiple schemas within that database for repository objects. But I can't seem to find any of that discussion in the forums anywhere. Is this possible? Could I, for example, have three separate repositories all using one SQL Server database but each using a different schema name in that database? This would greatly simplify database backup management for large numbers of repositories.
  10. I want to merge two repositories (or more) into a single repository without losing history of either repository, but have the full history of both available in the new repo. I have project1 and project2, each in their own repo (repo1 and repo2). Each project’s folder structure is set up the same—i.e. there’s a “/src” folder, a “/build” folder, etc in each. I want to bring each project (along with history) into a new repo where the /main will eventually (after some tweaking) have a folder structure such as: /project1/src /project1/build /project2/src /project2/build So, in Plastic I imagine doing this as follows: I’d like to have a new repo with a /main branch. And then create two child branches off that (called say “/main/repo1” and “/main/repo2”). And then on each of those child branches import the “/main” branch of each of the two repositories. This would let me have the full history of both on their own branches and then I could merge those two branches together after making changes to the folder structure in each so I could merge as above. However I can’t figure out how to do this in plastic. Attempting to “pull remote branch” or replicate a repo doesn’t work as desired in this case (I can’t sync a src repo to a specific branch in a target repo, at least not I am aware of). So first question, is there a way to synchronize an entire source repository to a specific child branch in a destination repository that I want to map as the main for the source repo? If so, how do I do that? Second question, if there’s no way to do that, then is there any other way to do what I want? I’m sure others have wanted to combine or split repositories over the years, how have you preserved history in that case?
  11. I'd like to setup Plastic to use LDAP authentication with SSL, connecting to Novell's eDirectory. There seem to be several issues with this. First, I can't seem to get Plastic to connect using SSL to any LDAP (tried both the LDAP interface to Active Directory as well as eDirectory). Are SSL connections not supported? Trying to bind to LDAP while sending credentials information across the network unencrypted simply won't work anywhere where security is a priority. Second, it seems that Plastic's implementation of "pure" LDAP is maybe lacking? I'm not sure. Does plastic truly support LDAP, or just the LDAP interface to Active Directory? On the configuration wizard for LDAP, I enter the host and domain for the eDirectory server. I then have tried several different ways of specifying the user, all to no avail. My normal user id in order to bind would be fully qualified, such as "uid=username,ou=orgunit,dc=subdomain,dc=topleveldomain". There simply seems no way for me to be able to get the "Test Connection" button to work. The response it gives is unhelpful, telling me the username, password, or domain is incorrect. I know the user and password are correct because I can bind using those credentials through an LDAP explorer. The thing I'm not so sure about is the domain. I've tried several different strings in that box, all to no avail. I've tried the host name, the "subdmian.topdomain", the "dc=subdomain,dc=topdomain" syntax, I even tried including the ou in that as well, all to no avail. What am I missing here? 1) Does Plastic support connecting to LDAP over SSL? 2) Does Plastic support connecting to Novell's eDirectory? If so, how does one go about doing that? I have no problems connecting using other tools. As an aside...would the developers of Plastic ever consider adding a plugin/extension capability for authentication? Many other unrelated products (such as Jira) do this, just defining an interface and allowing customer to implement their own mechanism. It would be nice, for example, to simply write a quick and dirty plugin that just forwards the credentials specified to our federated SSO provider.
  • Create New...